User Preferred Venue Seating

ABSTRACT

Methods and systems are provided for allowing a user to more easily select seats that are desirable to the user at event venues. Seating preferences of the user can be provided by the user or can be determined from historic user ticket purchase information. A ticket server can present the user with a map that shows those seating areas that meet at least some of the user&#39;s preferences. The user can use the map to determine which seats the user would like to purchase.

BACKGROUND

1. Technical Field

The present disclosure generally relates to electronic commerce and,more particularly, relates to the use of a venue seat map or the likethat indicates user preferred seating to help the user select seats whenpurchasing event tickets, such as for concerts and sporting events.

2. Related Art

The online purchasing of tickets for various events is common. Forexample, tickets for concerts and sporting events can be purchased froman online ticket seller, such as StubHub, Inc. The tickets can be paidfor via a payment provider account, such as that offered by Paypal, Inc.After being paid for, the purchased tickets can then be mailed to thecustomer or can sometimes be printed by the customer.

Typically, a customer must select one or more seats when purchasing suchtickets. Whether the tickets are being purchased online or from a brickand mortar merchant, a venue map is generally provided to help thecustomer select the seats. The venue map usually shows the differentseating areas and their relationship to an attraction area, such as astage, game court, or field. Ticket prices for each seating area areprovided, either on the map or elsewhere. Thus, a customer can use thevenue map to help determine which seats the customer would like topurchase for a particular event.

For example, a more dedicated football fan may be willing to pay morefor seats closer to the field than a less dedicated football fan.Further, the venue map can help a customer decide what part of the fieldthe customer wants to be near. The more dedicated football fan mayprefer to be close to center field.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a system for providing user preferred venueseating, according to an embodiment;

FIGS. 2A and 2B are flow charts showing a method for providing userpreferred venue seating, according to an embodiment;

FIGS. 3A and 3B are a flow charts showing further detail of the methodfor providing user preferred venue seating, according to an embodiment;and

FIG. 4 is a block diagram of an example of a computer that is suitablefor use in the system for providing user preferred venue seating,according to an embodiment.

DETAILED DESCRIPTION

Methods and systems are provided for allowing a user to more easilyselect seats that are desirable to the user at event venues. Accordingto an embodiment, the user can select a venue for which the user wantsto purchase event tickets. Seating preferences of the user can have beenpre-stored, such as with a ticket server. The ticket server can presentthe user with a map that shows those seats or seating areas that meet orare consistent at least some of the user's preferences. The user can usethe map to determine which seats the user would like to purchase.

According to an embodiment, a system can comprise a memory configured tostore information regarding a plurality of venues. The information caninclude at least one user preference for at least one of the venues. Oneor more processors can be operable to receive a communication includingan indication of a desire of a user to purchase tickets for an event ata selected one of the venues. The processor(s) can determine, via thememory, at least one user preference for the selected one of the venues.The processor(s) can send to the user information regarding anavailability of seats consistent with the at least one user preference.

According to an embodiment, at least one of the user preferences can beprovided to the system by the user. The user can provide thepreference(s) to the system during a user preference set up procedure,for example. The user can provide the preference(s) to the system whenpurchasing tickets. The use of such preferences by the system to providethe user with seats can be on a one time basis or can be for use with aplurality of ticket purchases by the user.

According to an embodiment, at least one of the user preferences can bedetermined by the system based upon user seating history. The system canuse a purchase history of the user at the venue for which tickets arecurrently being purchased to determine or infer user preferences. Thesystem can use a purchase history of the user at different venue fromthe venue for which tickets are currently being purchased to determineor infer user preferences. The system can use a purchase history of theuser from a plurality of venues for which tickets have previously beenpurchased to determine or infer user preferences.

According to an embodiment, the user preference(s) can comprise seatingcriteria preferences for the selected one of the venues. The userpreference(s) can include distance from an attraction area (such as astage, arena, court or field), an ability to see an attraction area, anability to see a specified part of the attraction area, an includeability to see the entire attraction area, an ability to hear sound fromthe attraction area, and/or a type of the seat (hard, padded, folding,box, etc.). The user preference(s) can include any criteria that theuser can use to decide which seats for the user would like to purchasetickets.

The user preference(s) can include a distance from another person. Forexample, the user can prefer to select seats based on where the user'sfriends are seated. The user can prefer to sit next to or within a givendistance from friends, family, co-workers, and the like. Thus, the usercan select seats next to one or more friends.

According to an embodiment, the user preferences can include seatingarea preferences for the selected venue. The user preferences caninclude specific seats for the selected venue. The user preferences caninclude both seating area preferences for the selected venue andspecific seats for the selected venue. For example, the user preferencecan be for specific seats, but can be for the seating area of thespecific seats if the specific seats are not available.

According to an embodiment, the user preference(s) can be negativepreferences. Negative preferences can be preferences that something notbe true. For example, a negative preference can be a preference that theuser not sit near a food stand, beverage stand, or restroom.

According to an embodiment, the user preferences can include seatingpreferences for the plurality of venues generally. The user preferencescan include seating criteria preferences for the plurality of venuesgenerally.

According to an embodiment, the processor(s) can determine, via thememory, one user preference for the selected one of the venues and theprocessors can send to the user information regarding an availability ofseats consistent with the one user preference. Alternatively, theprocessor(s) can determine, via the memory, a plurality of userpreferences for the selected one of the venues and the processors cansend to the user information regarding an availability of seatsconsistent with the one plurality of user preferences. As yet a furtheralternative, the processor(s) can determine, via the memory, all of theuser preferences for the selected one of the venues and the processor(s)can send to the user information regarding an availability of seatsconsistent with all of the user preferences.

According to an embodiment, the processor(s) can send to the user a mapshowing an availability of seats consistent with the one userpreference. Alternatively, the processor(s) can send to the user a mapshowing an availability of seats consistent with a plurality of the userpreferences. As yet a further alternative, the processor(s) can send tothe user a map showing an availability of seats consistent with all ofthe user preferences.

The map can use color coding to indication which seats are moreconsistent with the user preferences. For example, one color canindicate that a seat is consistent with one of the user preferences,another color can indicate that a seat is consistent with two of theuser preferences, and yet another color can indicate that a seat isconsistent with all of the user preferences. Thus, the color can dependupon how many of the user preferences are meet.

According to an embodiment, a method can include storing, in a memory,information regarding a plurality of venues, including at least one userpreference for at least one of the venues. A communication can bereceived via the one or more processors and the communication caninclude an indication of a desire of a user to purchase tickets for anevent at a selected one of the venues. At least one user preference forthe selected one of the venues can be determined via the one or moreprocessors. Information regarding an availability of seats consistentwith the at least one user preference can be sent to the user via theone or more processors.

A seat can be considered to be consistent with a preference if the seatmeets the preference. For example, if the preference is to be within 50feet of the stage, then all seats within 50 feet of the stage areconsistent with this preference. If a seat cannot be found that isconsistent with a particular preference, then the ticket server 130 canpresent the user with seats that come as close to being consistent withthat preference as possible. For example, if the preference is to bewithin 50 feet of the stage, but the closest available seats are 65 feetfrom the stage, then the seats 65 feet from the stage can be presentedto the user with the information that these are the closest availableseats.

According to an embodiment, the user can be presented with a map showingavailability of seats with different visual indicators based on adetermined desirability of a seat for the user. The different determineddesirabilities can be shown with different visual indicators. Forexample, the visual indicators can comprise size, brightness, and/orcolors. As further examples, the visual indicators can be differentcolors, patterns, icons, numbers, text, or graphics.

According to an embodiment, computer readable and executable code forinstructing the processor(s) to perform the method can be recorded on anon-transitory computer readable medium. For example, the method can berecorded on a hard drive, a solid state drive, magnetic tape, or opticalstorage media. The method can be recorded on any desired type ofnon-transitory computer readable medium.

FIG. 1 is a block diagram showing a venue seat and feature map system,according to an embodiment. A venue device 110 can be present at each ofa plurality of different event venues. The venue device 110 can provideinformation regarding events scheduled to be at the venue, regardingseating at the venue, and regarding features of the venue. The venuedevice 110 can provide such information to a ticker server 130. Theticket server 130 can obtain information regarding events scheduled tobe at various venues, information regarding seating, and informationregarding features of the various venues from other sources.

The venue device 110 can be a computer, a server, a computing tablet, ora mobile device, for example. The venue device 110 can have a processor111 and a memory 112. The processor 110 can execute a software programstored in the memory 112 for providing information regarding eventsscheduled to be at the venue, regarding seating, and regarding featuresof the venue. The venue device 110 can provide such information to theticket server and/or to a user device 120.

The venue device 110 can be disposed at the venue. The venue device 110can be disposed at a location other than the venue. Each venue can havea dedicated venue device 110. A plurality of different venues can sharea common venue device 110. For example, co-owned venues can share acommon venue device 110.

The user can have the user device 120. The user device 120 can be amobile device such as a cellular telephone, a tablet computer, a laptopcomputer, or the like. The user device 120 can be a non-mobile devicesuch as a home (land line) telephone, a table top computer, aninteractive set top box, or the like. The user device 120 can be anydevice or combination of devices that facilitate online ticketpurchasing.

The user device 120 can have a processor 121, a memory 122, and a globalpositioning system (GPS) 123. The processor 121 can execute anapplication or app 125 that facilitates the venue seat and feature mapmethod disclosed herein. The app 125 can be stored in the memory 122.The app 125 can provide a graphical user interface (GUI) for the userwhen purchasing tickets online. The app 125 can be a dedicated ticketpurchasing app. The app 125 can be part of another app, such as a Paypalpayment provider app.

The user device 120 can communicate with the venue device 110 and/or theticket server 130 via a network. For example, the user device 120 cancommunicate with the venue device 110 and/or the ticket server 130 viathe Internet 140. The user device 120 can communicate with the Internetvia either a wired connection or a wireless connection.

An online ticket seller, such as StubHub, Inc. can have the ticketserver 130. The ticket server 130 can facilitate online ticket sells.The ticket server 130 can have a processor 131 in communication with amemory 132. The processor 131 can be one or more processors. Theprocessor 131 can access a user account 133 and a venue account 134 thatare stored in the memory 132. The user account 133 can includeinformation regarding the user, e.g., identification information,preferences, account numbers, and purchase history. The venue account134 can include information regarding the venue, e.g., informationregarding events, seating, and features. The memory 132 can be separatefrom the ticker server and can have any number of user accounts 133 andvenue accounts 134. The memory 132 can be distributed, e.g., haveportions thereof disposed at a plurality of different locations.

The ticket 130 server can be one or more servers located at one or morelocations. Thus, the ticket server 130 can be geographically andoperationally distributed. The ticker server 130 can be part of anothersystem, such as a payment provider system.

The venue device 110 can communicate with the ticket server 130, such asvia a network. For example, the venue device 110 can communicate withthe ticket server 130 via the Internet 140. The venue device 110 cancommunicate with a plurality of different the payment servers 130. Theticket server 130 can communicate with a plurality of different thevenue devices 110. A plurality of different ticket servers 130 cancommunicate among themselves and can be considered herein as being thesame as a single ticket server 130. The user can utilize the user device120 to interact with the ticket server 130 so that the user can purchasetickets online.

The ticket server 130 can communicate with the venue device 110 toobtain information regarding the venue. For example, the ticket server130 can communicate with the venue device 110 to obtain informationregarding the scheduling of events at the venue and regarding featuresof the venue. The features of the venue can be dependent upon the eventsof the venue, e.g., the features of the venue can vary from event toevent.

FIGS. 2A-3B are flow charts that describe examples of operations of thevenue seat and feature map system according to embodiments thereof. Notethat one or more the steps described herein may be combined, omitted, orperformed in a different order, as desired or appropriate.

FIG. 2A is a flow chart showing a method for providing the venue seatand feature map, according to an embodiment. A user who wants topurchase one or more tickets for an event can open an online ticketseller's website, as shown in step 201. The user can open the ticketseller's website using the user device 120, for example. The ticketseller's website can be hosted on the ticket server 130, the venuedevice 110, or on any other server or device.

The user can specify an event, as shown in step 202. The event can be aconcert, sporting event, or any other type of event for which ticketsare sold. The event can be specified by stating a name of the event, avenue, and/or a date. For example, the event of Metallica concert atPacific Amphitheatre on Jun. 6, 2012 can be specified by entering“Metallica”, “Pacific Amphitheatre” and/or “Jun. 6, 2012” in one or moreentry boxes of the web site.

If the information entered is insufficient to uniquely identify theevent, then the web site can present the user with a list of possibleevents. For example, if the user only entered “Metallica” withoutstating a date or venue, then a list of upcoming Metallic concerts (tourdates) can be presented for the user to choose from. In this way, theuser can quickly find the event for which tickets are desired.

The user device 120 can provide GPS location information to the ticketserver 130 and the ticket server 130 can be configured to limit thevenues to one or more venues that are close to the location of the userdevice 120 when the user is attempting to specify the event. Forexample, if the user merely enters the word “Metallica” to identify anupcoming event and the GPS 123 of the user device 120 indicates that theuser is in Los Angeles, then the ticket server 130 can present the userwith the closest Los Angeles venue or all of the venues in Los Angeles.

The user can optionally be presented with only the next relevant eventin the user's area. For example, if the user merely enters the word“Metallica” to identify the upcoming event, then the user can bepresented with only the next Metallica concert at the closest venue tothe user. The user can then be requested to verify that the desiredevent is being presented.

After the event has been uniquely identified, the user can be presentedwith a map for the event venue, as shown in step 203. The map can beshown on the web site. The map can show the different seating areas andtheir relationship to the attraction area, e.g., the stage, game court,or field. The map can be printed by the user, if desired. The ticketprices for each seating area can be provided.

The map can also show at least one venue feature. For example, the mapcan show escalators, elevators, wheel chair accesses, restaurants, drinkstands, playgrounds, stores, parking lots, restrooms, and the like. Themap can also show any desired features or combination of desiredfeatures.

The map can show a best route from a selected seat to a feature. Forexample, the map can show a best route from a selected seat to a parkingarea that is designated for use by the ticket holder for that seat. As afurther example, the map can show a best route from a selected seat tothe nearest restroom. The best route can be defined as the shortestroute.

The best route can be defined by the user according to any desired usercriteria. For example, the map can show a best route for a party thatincludes a person in a wheelchair. Such a best route can take advantageof elevators and wheel chair ramps. As a further example, the map canshow a best route that passes by a restroom.

The map can show a best route from a selected seat to an alternatefeature. For example, if the user knows that the lines are likely to belong at the closest restroom, then the user can have the best route tothe next nearest restroom shown on the map.

The map can show alternate routes from a selected seat to a feature. Forexample, if the user knows that the shortest route to a drink stand islikely to be congested, then the user can have an alternate route, e.g.,the next shortest route, to the same drink stand displayed.

The best route can be determined by the ticket server 130 and can becommunicated to the user device 120. Alternatively, the best route canbe determined by the user device 120. As a further alternative, the bestroute can be determined by the venue device 110. The best route can bedetermined by any desired device according to any desired criteria.

The user device 120 can be a mobile device and the map, as well as anyor all of the features, can be stored on the user device 120. Forexample, the map can be used during the event to determine the locationof a feature, the location of an alternative feature (such as the nextclosest restroom when the closest restroom is full), the best route to afeature, or the next best route to a feature.

The user can mark locations on the map, as desired. For example, theuser can mark, high light, or drop a pin on the location of a friend'sseat elsewhere in the venue. The user can mark any desired location onthe map. The user can mark locations on the map for any desired purpose.For example, the user can mark locations on the map to show werefeatures are located or to define the starting points and ending pointsof routes.

GPS or another location service or combination of services can provideinstructions to the user for finding features or for following routes.For example, the app 125 of the user device 120 can provide verbalinstructions, such as via earphone, for the user to follow such that theuser does not need to view the map as the user moves about the venue. Inthis manner, the user can often view the event rather than look at theuser device 102.

The map can show best routes or alternate routes from one feature toanother feature. The map can show best routes or alternate routes fromany place at the venue to any other place at the venue. The user candesignate a starting point and an ending point for any such routes, suchas by dropping pins on the map as displayed on the user device 120.

The user device 120 can be a mobile device and the map can be updated inreal time. Thus, the map can be used in real-time to determine whichfeature to visit and can be used in real time to determine the best oran alternate route to the feature. Which feature to visit can bedetermined by taking into consideration factors such as brand preference(e.g., Coca Cola vs. Pepsi) and waiting lines. Brand preferences can beentered by the user during a setup process. The map can be updated inreal time to show the status of features. For example, if a drink standcloses or runs out of inventory, a note can be provided on the map.

The map can be interactive. For example, in response to the user makinga change on the map, such as adding or deleting a feature, the app 125or the ticket server 130 can suggest one or more other changes. Forexample, if the user deletes a beer concession, the app 125 or theticket server can suggest a nearby soft drink concession to be added.

The system can be anticipatory. For example, in response to the useradding a beer concession to the map, the app 125 or the ticket server130 can suggest that a nearby restroom also be added. Thus, the systemcan determine future needs of the map based upon current use of the map.

The best route to a selected one of the features can be determined bytaking into consideration such factors as distance to the feature andfoot traffic congestion (as reported by human operators and/or machinevision). Any preferences regarding routing can also be considered. Forexample, the user can specify that all routes be less than apredetermined distance. The user might want to specify short routes ofthe user is disabled, unable to walk longer distances, or simply prefersto walk shorter distances.

The app 125 can use the GPS 123 and the clock of the user device 120 todetermine that the user is at the venue. Prior to the event, the app 125can automatically offer to show the user where to park, how to get tothe seats, and where features such as the nearest concession stands andrestrooms are, for example. After the event, the app 125 can offer toshow the user the route to the parking lot, the nearest freeway, adestination (such as the user's home), or any other place.

The map can be a photographic map or virtual map. The map can thus showthe actual features or a simulation of the actual features. Thephotographic may can be updated, such as in real time. The virtual mapcan be photorealistic.

The user can specify which venue features are to be shown on the map, asshown in step 204. The user can specify which venue features are to beshown on the map prior to the map being displayed on the web site. Forexample, the user can specify which venue features are to be shown onthe map via the use of a menu, such as a drop down menu of the app 125.

The user can specify which venue features are to be shown after the mapis displayed by the web site. For example, the user can specify whichvenue features are to be shown on the map via the use of a drop downmenu that is provided on the map or along with the map. The venuefeatures can be specified iteratively. That is, the venue features canbe changed repeatedly until the user is satisfied with the featuresdisplayed.

The map can be update to show the selected features, as shown in step205. Thus, each time that the user changes the features that areselected to be shown on the map, the map can be updated to shown thenewly selected features. Such updating can be facilitated viacommunication between the user device 120 (from which the features canbe selected) and the ticket server 130 (which can add the features tothe map of the website displayed on the user device 120.

Alternatively, the ticket server 130 can download the map and all of thefeatures to the user device 120 and the map can be changed by the userdevice 120 without requiring the continued cooperation of the ticketserver 130. For example, an app 125 executed in the user device, a Javaapplet, or the like can facilitate changing of the features shown on themap without involvement of the ticket server 130. In this manner,network traffic can be minimized, bandwidth efficiency can be enhances,and the bandwidth requirements of the device 120 and/or the app 125 canbe reduced.

The user can refer to the selected features when deciding where to sitat the venue, as shown in step 206. Thus, the user can display thefeatures that are important to the user for deciding where to sit at avenue. The user can then determine which seats are close enough to thosefeatures to be desirable to the user and can select the seats on thisbasis. For example, if the user is going to bring children to the event,then the user may want to select seats near a playground. As a furtherexample, if the user intends to eat during the event, the user may wantto be near a restaurant, possible a particular restaurant such as ahotdog stand or pizza shop.

The user can specify that selected features be shown on the map onlywhen grouped with a specified distance of one another. For example, theuser can specify that the drink stands and restrooms be shown on the maponly when the drink stands are within fifty feet of the restrooms.

Features such as restaurants and drink stands can be identifiedgenerically on the map. For example, the words “Restaurant” and “DrinkStand” can simply be used to indicate these features on the map.Alternatively, more descriptive terms can be used. For example, a nameof the restaurant or a name of the products being sold can be shown onthe map. For example, the words “Burger King Restaurant” or “Coca ColaDrink Stand” can be used. Any words, logos, designs, icons, or the likewhich indicate to the user what is at a location on the map can be used.

The user can choose to color code the features. For example, all foodconcessions can be color coded red, all drink concessions can be colorcoded blue, and all restrooms can be color coded green. Such colorcoding can help the user to quickly locate the desired feature,especially when the map is being displayed on the comparatively smallscreen of a mobile user device 120.

The user can define words, logos, designs, icons, or the like to bedisplayed upon the map for the features. Thus, the user can select suchwords, logos, designs, icons, or the like from words, logos, designs,icons, or the like presented by the website and/or can custom designwords, logos, designs, icons, or the like for presentation on the map.For example, the user can select a Pepsi bottle from a list of graphicimages to be used for all drink stands and can type the word “EATS” tobe used for all restaurants. In this manner, the user can customize themaps, thus potentially making the event more appealing to the user andthereby increasing ticket sells for the online ticket seller.

The user can pre-define what features are to be shown on the map, suchas during a setup process. This pre-definition of features to be shownon the map can then apply to all subsequently displayed maps. Forexample, the user can select restrooms and beer stands to be displayedon all future maps. Thus, any maps displayed by the venue seat andfeature map in the future will automatically show the restrooms and beerstands in addition to the seating areas and attraction area.

The user can pre-define a plurality of different feature groups, such asduring a setup process. Each feature group can contain a different setof features that are to be used for a different type of event. This, theuser can pre-define one feature group for rock concerts and anotherfeature group for monster truck rallies. For example, the user canpre-define one feature group containing drink stands and restrooms forthe rock concerts and can pre-define another feature group containingplaygrounds and souvenir shops for the monster truck rallies.

The venue seat and feature map system can automatically apply thepre-defined group for the user. Thus, when a map for a rock concert isbeing displayed, then the venue seat and feature map system canautomatically apply the pre-defined group for rock concerts to the map.The user can then change which pre-defined group is to be use, if theuser desires to do so. Alternatively, the user can select whichpre-defined group is to be shown prior to the map being displayed.

This pre-definition of features to be shown on the map can then apply toall subsequently displayed maps. For example, the user can selectrestrooms and beer stands to be displayed on all future maps. Thus, anymaps displayed by the venue seat and feature map in the future willautomatically show the restrooms and beer stands in addition to theseating areas and attraction area.

Any such customization or pre-definition of features to be shown on amap can last indefinitely or can last for a pre-determined amount oftime. Such customization or pre-definition of features to be shown on amap can last for a day, a week month, a season, a year, multiple years,or any other length of time. For example, a season ticket holder may setup a custom map for a baseball team that only applies when thatparticular baseball team is playing and that defines the features to beshown on the map and the words or graphics to be displayed to indicateeach feature. Other custom maps can be user by the season ticket holderfor basketball games and football games.

When the map is initially sent to the user, the map can show all of thefeatures available for the event, some of the features available for theevent, or none of the features available for the event. The user cansubsequently define which of the features available for the event theuser desires to see on the map and the map can be changed to show onlythe desired features.

FIG. 2B is a flow chart showing further detail of the method for thevenue seat and feature map, according to an embodiment. A ticket server130 can store information regarding events in a memory 132, as shown instep 301. The information can include venue maps that show seating areasand an attraction area such as a stage, court or field. Informationregarding features of the venue can be stored in the memory 132. Forexample, information regarding the location, routes to, and items soldby stores, drink stands, shops, and the like can be stored in the memory132. Information regarding which events at the each venue will utilizesuch features can be stored in the memory 132.

The ticket server 130 can receive a communication that includes anindication of a desire of the user to purchase tickets for a specifiedevent, as shown in step 302. For example, the user can open the app 125on the user device 120. The app 125 can initiate communication with theticket server 130. From the app 125, the user can select the event forwhich the user desires to purchase tickets. Generally, the event will bedefined by specifying an attraction, e.g., a performer or a team, avenue, and/or a date.

The user can access a web site of the online ticket seller, with orwithout using the app 125. The user can select the event for which theuser desires to purchase tickets, can specify the features, and can viewthe map via the web site.

The ticket server 130 can determine which map corresponds to thespecified even, as shown in step 303. The ticket server 130 candetermine which map corresponds to the specified event via a data basestored in the memory 132, for example. The ticket server 130 can sendthe map, showing any specified features, to the user as shown in step304.

FIG. 3A shows a flow chart having additional detail regarding the userpreferred venue seating wherein the user provides the ticket server 130with user seating preferences, according to an embodiment. A user canprovide the ticket server 130 with seat preferences, as shown in step501. For example, the seat preferences can be provided to the ticketserver 130 during a seating preferences setup procedure performed by theuser, such as when setting up an account with the ticket seller.

The user can select a venue/event for a potential ticket or seatpurchase, as shown in step 502. The venue/event selection can be part ofa ticket purchase that is performed in cooperation between the user andthe ticket seller, such as via the user device 120 and the ticket server130.

The user can be shown seats that are consistent with the seatpreferences provided by the user, as shown in step 503. The seats can beshown to the user by the ticket server 130. The seats can be shown astext, graphics, or any combination of text and graphics. For example,the seats can be shown on a map of the venue with those seats that areconsistent with the seat preferences being highlighted.

The user can select the seats for the ticket purchase, as shown in step504. The user can select the seats by filling out a form, e.g., enteringtext, or by selecting the seats, e.g., with a cursor or by touching atouch screen.

The user can purchase the tickets, as shown in step 505. The purchasecan be done either online or at a brick and mortar ticket outlet. Thepurchase can be done online by confirming with the ticket server 130that the user wants to make the purchase.

FIG. 3B shows a flow chart having additional detail regarding the userpreferred venue seating wherein the ticket server 130 determines userseating preferences from user historic seating information, according toan embodiment. The user can select a venue/event for a potential ticketor seat purchase, as shown in step 601. The venue/event selection can bepart of a ticket purchase that is performed in cooperation between theuser and the ticket seller, such as via the user device 120 and theticket server 130.

The ticket server 130 can use historic information regarding ticketpurchases of the user to determine seat preferences for the user, asshown in 602. For example, if the user has always selected a particularseating area in the past, this particular area can be considered to be apreferred seating area for the user. Any criteria can be used todetermine preferences from historic information.

The user can be shown seats that are consistent with the seatpreferences provided by the user, as shown in step 603. The seats can beshown to the user by the ticket server 130. The seats can be shown astext, graphics, or any combination of text and graphics. For example,the seats can be shown on a map of the venue with those seats that areconsistent with the seat preferences being highlighted.

The user can select the seats for the ticket purchase, as shown in step604. The user can select the seats by filling out a form, e.g., enteringtext, or by selecting the seats, e.g., with a cursor or by touching atouch screen.

The user can purchase the tickets, as shown in step 605. The purchasecan be done either online or at a brick and mortar ticket outlet. Thepurchase can be done online by confirming with the ticket server 130that the user wants to make the purchase.

In implementation of the various embodiments, embodiments of theinvention may comprise a personal computing device, such as a personalcomputer, laptop, PDA, cellular phone or other personal computing orcommunication devices. The online ticket seller may comprise a networkcomputing device, such as a server or a plurality of servers, computers,or processors, combined to define a computer system or network toprovide the online ticket sales.

In this regard, a computer system may include a bus or othercommunication mechanism for communicating information, whichinterconnects subsystems and components, such as a processing component(e.g., processor, micro-controller, digital signal processor (DSP),etc.), a system memory component (e.g., RAM), a static storage component(e.g., ROM), a disk drive component (e.g., magnetic or optical), anetwork interface component (e.g., modem or Ethernet card), a displaycomponent (e.g., CRT or LCD), an input component (e.g., keyboard orkeypad), and/or cursor control component (e.g., mouse or trackball). Inone embodiment, a disk drive component may comprise a database havingone or more disk drive components.

The computer system may perform specific operations by processor andexecuting one or more sequences of one or more instructions contained ina system memory component. Such instructions may be read into the systemmemory component from another computer readable medium, such as staticstorage component or disk drive component. In other embodiments,hard-wired circuitry may be used in place of or in combination withsoftware instructions to implement the invention.

FIG. 4 is a block diagram of a computer system 400 suitable forimplementing one or more embodiments of the present disclosure. Invarious implementations, the PIN pad and/or merchant terminal maycomprise a computing device (e.g., a personal computer, laptop, smartphone, tablet, PDA, Bluetooth device, etc.) capable of communicatingwith the network. The merchant and/or payment provider may utilize anetwork computing device (e.g., a network server) capable ofcommunicating with the network. It should be appreciated that each ofthe devices utilized by users, merchants, and payment providers may beimplemented as computer system 400 in a manner as follows.

Computer system 400 includes a bus 402 or other communication mechanismfor communicating information data, signals, and information betweenvarious components of computer system 400. Components include aninput/output (I/O) component 404 that processes a user action, such asselecting keys from a keypad/keyboard, selecting one or more buttons orlinks, etc., and sends a corresponding signal to bus 402. I/O component404 may also include an output component, such as a display 411 and acursor control 413 (such as a keyboard, keypad, mouse, etc.). Anoptional audio input/output component 405 may also be included to allowa user to use voice for inputting information by converting audiosignals. Audio I/O component 405 may allow the user to hear audio. Atransceiver or network interface 406 transmits and receives signalsbetween computer system 400 and other devices, such as a user device, amerchant server, or a payment provider server via network 460. In oneembodiment, the transmission is wireless, although other transmissionmediums and methods may also be suitable. A processor 412, which can bea micro-controller, digital signal processor (DSP), or other processingcomponent, processes these various signals, such as for display oncomputer system 400 or transmission to other devices via a communicationlink 418. Processor 412 may also control transmission of information,such as cookies or IP addresses, to other devices.

Components of computer system 400 also include a system memory component414 (e.g., RAM), a static storage component 416 (e.g., ROM), and/or adisk drive 417. Computer system 400 performs specific operations byprocessor 412 and other components by executing one or more sequences ofinstructions contained in system memory component 414. Logic may beencoded in a computer readable medium, which may refer to any mediumthat participates in providing instructions to processor 412 forexecution. Such a medium may take many forms, including but not limitedto, non-volatile media, volatile media, and transmission media. Invarious implementations, non-volatile media includes optical or magneticdisks, volatile media includes dynamic memory, such as system memorycomponent 414, and transmission media includes coaxial cables, copperwire, and fiber optics, including wires that comprise bus 402. In oneembodiment, the logic is encoded in non-transitory computer readablemedium. In one example, transmission media may take the form of acousticor light waves, such as those generated during radio wave, optical, andinfrared data communications.

Some common forms of computer readable and executable media include, forexample, floppy disk, flexible disk, hard disk, magnetic tape, any othermagnetic medium, CD-ROM, any other optical medium, punch cards, papertape, any other physical medium with patterns of holes, RAM, ROM,E2PROM, FLASH-EPROM, any other memory chip or cartridge, carrier wave,or any other medium from which a computer is adapted to read.

In various embodiments, execution of instruction sequences forpracticing the invention may be performed by a computer system. Invarious other embodiments, a plurality of computer systems coupled by acommunication link (e.g., LAN, WLAN, PTSN, or various other wired orwireless networks) may perform instruction sequences to practice theinvention in coordination with one another.

Modules described herein can be embodied in one or more computerreadable media or be in communication with one or more processors toexecute or process the steps described herein.

A computer system may transmit and receive messages, data, informationand instructions, including one or more programs (i.e., applicationcode) through a communication link and a communication interface.Received program code may be executed by a processor as received and/orstored in a disk drive component or some other non-volatile storagecomponent for execution.

Where applicable, various embodiments provided by the present disclosuremay be implemented using hardware, software, or combinations of hardwareand software. Also, where applicable, the various hardware componentsand/or software components set forth herein may be combined intocomposite components comprising software, hardware, and/or both withoutdeparting from the spirit of the present disclosure. Where applicable,the various hardware components and/or software components set forthherein may be separated into sub-components comprising software,hardware, or both without departing from the scope of the presentdisclosure. In addition, where applicable, it is contemplated thatsoftware components may be implemented as hardware components andvice-versa—for example, a virtual Secure Element (vSE) implementation ora logical hardware implementation.

Software, in accordance with the present disclosure, such as programcode and/or data, may be stored on one or more computer readable andexecutable mediums. It is also contemplated that software identifiedherein may be implemented using one or more general purpose or specificpurpose computers and/or computer systems, networked and/or otherwise.Where applicable, the ordering of various steps described herein may bechanged, combined into composite steps, and/or separated into sub-stepsto provide features described herein.

As used herein, the term “store” can include any business or place ofbusiness. The store can be a brick and mortar store or an online store.The store can be any person or entity that sells a product.

As used herein, the term “product” can include any item or service. Aproduct can be anything that can be sold.

As used herein, the term “merchant” can include any seller of products.The term merchant can include a store. The products can be sold from astore or in any other manner.

As used herein, the term “mobile device” can include any portableelectronic device that can facilitate data communications, such as via acellular network and/or the Internet. Examples of mobile devices includecellular telephones, smart phones, tablet computers, and laptopcomputers.

As used herein, the term “attraction area” can include any area, stage,field, court, or other structure or area when performers, players, orthe like perform or play. The term “attraction area” can include anyplace that the spectators desire to view at the venue.

As used herein, the term “game field/court” can include any field,court, arena, or other structure or area when a game is played.

As used herein, the term “restaurant” can include any restaurant, coffeeshop, café, deli, sandwich shop, or any other place that sells food orbeverages.

As used herein, the term “drink stand” can include any place where anybeverage is sold.

As used herein, the term “playground” can include any place that hastoys, swings, slides, or other things for children to play on or with.The term “playground” can be included any place where children areexpected to play.

As used herein, the term “store” can include any souvenir shop, giftshop, or other place where a user can shop. As used herein, the term“store” can include any place where products are sold.

The foregoing disclosure is not intended to limit the present inventionto the precise forms or particular fields of use disclosed. It iscontemplated that various alternate embodiments and/or modifications tothe present invention, whether explicitly described or implied herein,are possible in light of the disclosure. Having thus described variousexample embodiments of the disclosure, persons of ordinary skill in theart will recognize that changes may be made in form and detail withoutdeparting from the scope of the invention. Thus, the invention islimited only by the claims.

1. A system comprising: a memory storing information regarding aplurality of venues, including a plurality of user preferences for atleast one of the venues; one or more processors operable to: receive acommunication including an indication of a desire of a user to purchasetickets for an event at a selected one of the venues; determine, via thememory, a plurality of user preferences for the selected one of thevenues; send to the user information regarding an availability of seatsconsistent with the plurality of user preferences; and visually indicateto the user which seats meet more of the plurality of user preferences.2. The system of claim 1, wherein the plurality of user preferences isprovided to the system by the user.
 3. The system of claim 1, whereinthe plurality of user preferences is determined by the system based uponuser seating history.
 4. The system of claim 1, wherein the plurality ofuser preferences comprises seating criteria preferences for the selectedone of the venues.
 5. The system of claim 1, wherein the plurality ofuser preferences comprises seating criteria preferences for the selectedone of the venues and the seating criteria include a distance from anattraction area.
 6. The system of claim 1, wherein the plurality of userpreferences comprises seating criteria preferences for the selected oneof the venues and the seating criteria include an ability to see anattraction area.
 7. The system of claim 1, wherein the plurality of userpreferences comprises seating criteria preferences for the selected oneof the venues and the seating criteria include an ability to see aspecified part of the attraction area.
 8. The system of claim 1, whereinthe plurality of user preferences comprises seating criteria preferencesfor the selected one of the venues and the seating criteria include anability to see an entire attraction area.
 9. The system of claim 1,wherein the plurality of user preferences comprises seating criteriapreferences for the selected one of the venues and the seating criteriainclude an ability to hear sound from an attraction area.
 10. The systemof claim 1, wherein the plurality of user preferences comprises seatingcriteria preferences for the selected one of the venues and the seatingcriteria include a type of the seat.
 11. The system of claim 1, whereinthe plurality of user preferences comprise seating area preferences forthe selected one of the venues.
 12. The system of claim 1, wherein theplurality of user preferences comprise specific seats for the selectedone of the venues.
 13. The system of claim 1, wherein the plurality ofuser preferences comprise seating preferences for the plurality ofvenues generally.
 14. The system of claim 1, wherein the plurality ofuser preferences comprise seating criteria preferences for the pluralityof venues generally. 15-16. (canceled)
 17. The system of claim 1,wherein: the processor(s) determine, via the memory, all of the userpreferences for the selected one of the venues; and the processors sendto the user information regarding an availability of seats consistentwith all of the user preferences.
 18. The system of claim 1, wherein amap shows the availability of seats with different visual indicatorsbased on a determined desirability of a seat for the user, whereindifferent determined desirabilities are shown with different visualindicators.
 19. The system of claim 18, wherein the visual indicatorscomprise size, brightness, colors, or a combination thereof.
 20. Amethod comprising: storing, in a memory, information regarding aplurality of venues, including a plurality of user preferences for atleast one of the venues; receiving, via the one or more processors, acommunication including an indication of a desire of a user to purchasetickets for an event at a selected one of the venues; determining, viathe one or more processors, a plurality of user preferences for theselected one of the venues; sending, via the one or more processors, tothe user information regarding an availability of seats consistent withthe plurality of user preferences; and presenting the user a map showingavailability of seats with different visual indicators based on adetermined desirability of a seat for the user, wherein differentdetermined desirabilities are shown with different visual indicators andthe different visual indicators indicate which seats meet more of theplurality of user preferences.
 21. A computer program product comprisinga non-transitory computer readable medium having computer readable andexecutable code for instructing one or more processors to perform amethod, the method comprising: storing information regarding a pluralityof venues, including plurality of user preferences for at least one ofthe venues; receiving a communication including an indication of adesire of a user to purchase tickets for an event at a selected one ofthe venues; determining a plurality of user preferences for the selectedone of the venues; sending to the user information regarding anavailability of seats consistent with the plurality of user preferences;and presenting the user a map showing availability of seats withdifferent visual indicators based on a determined desirability of a seatfor the user, wherein different determined desirabilities are shown withdifferent visual indicators and the different visual indicators indicatewhich seats meet more of the plurality of user preferences.
 22. Themethod of claim 20, wherein the visual indicators comprise size,brightness, colors, or a combination thereof.
 23. The computer programproduct of claim 21, wherein the visual indicators comprise size,brightness, colors, or a combination thereof.